Perlin Noise has been a mainstay of computer graphics since 1985, being the core procedure that enables procedural shaders to produce natural appearing materials. Now that real-time graphics hardware has reached the point where memory bandwidth is more of a bottleneck than is raw processing power, it is imperative that the lessons learned from procedural shading be adapted properly to real-time hardware platforms.
There are two major issues involved in this adaptation: (i) A common procedural shading abstract machine language, to enable the capabilities that were first introduced in [Perlin, K., An Image Synthesizer, Computer Graphics; Vol. 19 No. 3, incorporated by reference herein], and subsequently adapted by the motion picture special effects industry, and (ii) a standard, fast, robust, differentiable and extensible Noise function contained in the instruction set of this abstract machine language. This disclosure addresses the second of these two issues.
The ideal of Perlin Noise can be separated from the shortcomings of any particular implementation which aims to approximate this ideal. [Perlin, K., An Image Synthesizer, Computer Graphics; Vol. 19 No. 3, incorporated by reference herein] outlined a number of characteristics for an ideal Perlin Noise. Ideally, a hardware-implemented standard would conform to this ideal, without suffering from any shortcomings.
The traditional Perlin Noise algorithm, while very useful, had some shortcomings that would be of particular consequence in a real-time setting and in a hardware implementation. This disclosure describes a new method that suffers from none of these shortcomings. Shortcomings which are addressed in this disclosure include:                Lack of a single standard reference implementation: Unlike the situation to date with software Noise, all implementations should ideally produce the same result for the same input, up to the inherent limitation imposed by limited bit depth, on all platforms and implementations.        Requiring many multiplies: The original formulation of Noise required, as a subset of its component calculations, that a gradient be evaluated at each corner of a cube surrounding the input point. Each gradient evaluation requires an inner product, which costs three multiplies, at each of eight cube vertices, for a total of 24 multiplies. A multiply is expensive in its use of hardware, relative to such other operations as bit manipulation and addition. In a hardware implementation, it would be greatly advantageous to redefine Noise so that it does not require this large number of multiplies.        Visually significant anisotropy: The Noise function is ideally a directionally insensitive (isotropic) signal. However, the original implementation, because it consists of adjoining 3D tricubic patches, contains visible directional artifacts which are an unavoidable consequence of its underlying algorithm. This is also the case for approximations that mimic that implementation, such as nVidia's recent Noise patch [Technical Demos—Perlin Noise http://www.nvidia.com/Support/Developer Relations/Technical Demos, Disclosed Nov. 10, 2000, incorporated by reference herein].        
Specifically, when these implementations of Perlin Noise are applied to a rotated domain, a casual viewer of the result can easily pick out the orientation of the rotated coordinate grid. Ideally, it should be impossible for a casual viewer to infer the orientation of the rotated coordinate system, when presented with the texture image produced by Perlin Noise applied to a rotated domain.                Gradient artifacts: The original Noise function uses a piecewise cubic blending function 3t2−2t3 in each dimension. When the Noise function uses this blending function, then visually noticeable discontinuities appear in the derivative of the Noise function along the 3D tricubic patch boundaries of the Noise function's domain, since the derivative of the derivative of this blending function contains a piecewise constant term.        Difficulty of computing a derivative: The original Noise algorithm contains an associated derivative function which is difficult to compute algorithmically, since it consists of a product of a linear function with three cubic splines. In non-real time applications, the Noise derivative has generally been approximated by evaluating differences of Noise at closely spaced sample points along the three coordinate axes. This has required evaluating the Noise function four times. In a hardware implementation such an approach would not only consume valuable gates, but would be impractical for any method that used less than full floating point precision, since the use of difference methods to computer derivative requires high bit depth. It is desirable for a hardware Noise standard to possess an associated derivative function that can be computable analytically, at a cost of a relatively modest number of gates. This is particularly important when using Noise to compute normal perturbations and other effects that use the derivative of Noise, as opposed to its value.        Need for table memory: The original Noise algorithm relied on a number of table lookups, which are quite reasonable in a software implementation, but which in a hardware implementation are expensive and constitute a cost bottleneck, particularly when multiple instances of the Noise function are required in parallel. Ideally, a Noise implementation should not rely on the presence of tables of significant size.        Memory-limited extent of the volume tile: Perlin Noise is generally defined within a repeating volumetric tile. In previous implementations, the extent of this tile has been limited by table size. Ideally, Noise should be based on a virtual volume which is scalable, inexpensively, to any extent.        Expense of generalizing to higher dimensions: The original implementation of Noise was based on a cubic lattice. Moving to higher dimensions causes implementation cost to more than double with each additional dimension, since it requires moving to an n-dimensional hypercube lattice. In hardware, this cost would be measured as a product of gate count and number of successive instruction cycles. For example, the cost of Noise over four dimensions is at least twice the cost of Noise over three dimensions. Quite soon, it will be desirable to extend the standard from 3D Noise to 4D Noise (to account for time-varying volume textures), and thereafter to 5D Noise (to specify textured BRDFs). It is important to address this issue now.        Lack of separation between signal and reconstruction: The original Noise presented the pseudo-random gradient field (its “signal”) and its tricubic interpolation scheme (its “reconstruction filter”) as a single functional object. It would be greatly advantageous for a method to allow these two operations to be cleanly separable, so that other signals which share the same hardware and abstract machine language can also use this reconstruction filter.        
In non-real time applications, in which perfection of the final result is far more important than is processing budget, such as is the case in the use of Noise for motion picture special effects, it is possible to “fudge” some these artifacts by applying Noise multiple times. For example, the procedural shaders for the scene depicting ocean waves in the recent film “The Perfect Storm” combined about 200 shader procedures, each of which invoked Perlin Noise. In contrast, for real-time applications, where the cost of every evaluation counts, it is crucial that Noise itself be artifact free, that its derivative be directly computable, and that it incur a relatively small computational cost.